Is this for Monax? If so, I would like to see how this fits in with the existing protos or proposed workflow. Do you have any example configs for this?

Is this for Monax? If so, I would like to see how this fits in with the existing protos or proposed workflow. Do you have any example configs for this?

Yes, this is for Monax, so the vendors can use all real data like ownership_voucher.
I haven't created the PR yet, but when creating the Bootz server, this Config proto should be read from a file and provided to the Bootz server.

Is this for Monax? If so, I would like to see how this fits in with the existing protos or proposed workflow. Do you have any example configs for this?

Yes, this is for Monax, so the vendors can use all real data like ownership_voucher. I haven't created the PR yet, but when creating the Bootz server, this Config proto should be read from a file and provided to the Bootz server.

In that case, could you either edit the existing Monax protos under server/tests/proto or move the config there? The reason I ask is because this file is very similar to server/tests/proto/test.proto

Is this for Monax? If so, I would like to see how this fits in with the existing protos or proposed workflow. Do you have any example configs for this?

Yes, this is for Monax, so the vendors can use all real data like ownership_voucher. I haven't created the PR yet, but when creating the Bootz server, this Config proto should be read from a file and provided to the Bootz server.

In that case, could you either edit the existing Monax protos under server/tests/proto or move the config there? The reason I ask is because this file is very similar to server/tests/proto/test.proto

Besides Monax, this proto definition will be referenced by artifact_manager and chassis_manager as argument in their respective New() function, as well as by server_emulator and client_emulator, so I am not sure whether putting it into the test directory is appropriate.

Even without doing any test (Monax or not), this proto definition is still required.

Is this for Monax? If so, I would like to see how this fits in with the existing protos or proposed workflow. Do you have any example configs for this?

Yes, this is for Monax, so the vendors can use all real data like ownership_voucher. I haven't created the PR yet, but when creating the Bootz server, this Config proto should be read from a file and provided to the Bootz server.

In that case, could you either edit the existing Monax protos under server/tests/proto or move the config there? The reason I ask is because this file is very similar to server/tests/proto/test.proto

Besides Monax, this proto definition will be referenced by artifact_manager and chassis_manager as argument in their respective New() function, as well as by server_emulator and client_emulator, so I am not sure whether putting it into the test directory is appropriate.

Even without doing any test (Monax or not), this proto definition is still required.

I'm not sure how this config proto will be used in the production (non-test instance). Doesn't this config have to contain an exhaustive list of the inventory and other artifacts? In the real world, we fetch these from external systems.

Is this for Monax? If so, I would like to see how this fits in with the existing protos or proposed workflow. Do you have any example configs for this?

Yes, this is for Monax, so the vendors can use all real data like ownership_voucher. I haven't created the PR yet, but when creating the Bootz server, this Config proto should be read from a file and provided to the Bootz server.

In that case, could you either edit the existing Monax protos under server/tests/proto or move the config there? The reason I ask is because this file is very similar to server/tests/proto/test.proto

Besides Monax, this proto definition will be referenced by artifact_manager and chassis_manager as argument in their respective New() function, as well as by server_emulator and client_emulator, so I am not sure whether putting it into the test directory is appropriate.
Even without doing any test (Monax or not), this proto definition is still required.

I'm not sure how this config proto will be used in the production (non-test instance). Doesn't this config have to contain an exhaustive list of the inventory and other artifacts? In the real world, we fetch these from external systems.

This config profo is only for the open source Bootz. This config proto itself as well as its consumers: artifact_manager, chassis_manager, bootz_emulator and client_emulator won't be sync'ed back to our internal codebase.

Our internal Bootz will use a different version of artifact_manager and chassis_manager, which implements the same interfaces as the open source ones.

Is this for Monax? If so, I would like to see how this fits in with the existing protos or proposed workflow. Do you have any example configs for this?

Yes, this is for Monax, so the vendors can use all real data like ownership_voucher. I haven't created the PR yet, but when creating the Bootz server, this Config proto should be read from a file and provided to the Bootz server.

In that case, could you either edit the existing Monax protos under server/tests/proto or move the config there? The reason I ask is because this file is very similar to server/tests/proto/test.proto

Besides Monax, this proto definition will be referenced by artifact_manager and chassis_manager as argument in their respective New() function, as well as by server_emulator and client_emulator, so I am not sure whether putting it into the test directory is appropriate.
Even without doing any test (Monax or not), this proto definition is still required.

I'm not sure how this config proto will be used in the production (non-test instance). Doesn't this config have to contain an exhaustive list of the inventory and other artifacts? In the real world, we fetch these from external systems.

This config profo is only for the open source Bootz. This config proto itself as well as its consumers: artifact_manager, chassis_manager, bootz_emulator and client_emulator won't be sync'ed back to our internal codebase.

Our internal Bootz will use a different version of artifact_manager and chassis_manager that implement the same interface.

I have created another PR of artifact_manager to demonstrate how this config proto is consumed, but due to the dependency, I have to create the new PR containing both artifact_manager package and this config proto package together in the same PR, otherwise the new PR will fail the building test due to dependency.

I think we can put Monax aside for now, because we are still too far away from implementing any Monax test.

The major use of this config proto definition is to replace the current Bootz server emulator command line arguments defined as below:
https://github.com/openconfig/bootz/blob/main/server/emulator/main.go#L38-L42

I will remove all those command line arguments and only use a single textproto file generated from this config proto definition as the command line argument for starting a Bootz server emulator.

The client emulator will do the same, by also using the same single textproto file generated from this config proto definition as the command line argument for starting a Bootz client emulator.

How we should start the Monax Bootz test can be discussed later and doesn't have to use this config proto, but we still need this proto for the server+client emulator. Currently those emulators generate lots of fake certs/keys/vouchers internally, but we can't do that anymore as we are going to ask the vendors to test with real switches, so all those things will be provided by this textproto.

I hope my explanation makes things a little clearer now.